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EVALUATION 


1.  The  objective  of  this  effort  was  to  modify  the  software  structure 
of  RADC's  existing  Interactive  Radar  Simulation  System  (IRSS)  to  make 
a  major  improvement  in  the  ease  of  using  the  system  and  to  shorten  the 
turn-around  time  in  getting  plotted  output  results.  These  marked 
improvements  will  be  reflected  in  greater  use  by  RADC  engineers  in 
areas  of  ECCM,  new  radar  parametric  design  studies  and  determination 
of  problem  areas  or  causes  in  existing  radar  systems. 

2.  This  effort  is  part  of  RADC  TP0-4B. 

/.-*/-  7^rriio  .  i'<; . .  , 

STANLEY  D.  DAVIS 
Project  Engineer 
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INTRODUCTION 


In  designing  a  radar  system  the  goal  is  to  combine 
various  components  in  such  a  way  that  a  certain  capability 
is  created.  In  a  sense  the  problem  of  building  a  system  to 
satisfy  a  requirement  is  a  problem  of  implementing  a  model. 
That  is  to  say,  for  any  object  constructed  by  man  the  idea 
came  first,  then  the  object  appeared  after  a  way  was  found 
to  implement  the  idea.  In  the  more  formal  language  of 
systems  engineering,  ideas  are  mental  models.  Initially  in 
the  design  process  we  envision  a  perfect  system  composed  of 
flawless  components  <a  Perfect  Model).  Then,  faced  with 
reality,  we  back  away  and  accept  compromises  in 
performance.  Some  are  easy  to  accept?  others  are  more 
difficult.  All  the  while  we  must  ensure  that  the 
cumulative  effect  of  these  compromises  will  not  render  the 
total  system  useless. 

In  developing  a  complex  system  the  design  and 
development  process  involves  a  progressive  refinement  of 
models,  especially  with  regard  to  subsystem  specification. 
When  large  complex  systems  are  involved  it  is  desirable  to 
implement  a  simulation  model  of  the  entire  system  based  on 
the  design  of  each  individual  subsystem.  In  this  way  the 
system  designer  can  determine  marginal  areas  in  his  design 
and  correct  them.  Simulation  models  can  be  used  to 
optimize  designs  and  reduce  some  of  the  risks  involved  in 
system  development . 

Over  the  past  several  years  a  comprehensive  Radar 
System  Simulation  Model  <RADSIM)  computer  program  has  been 
available  for  use  in  radar  system  analysis  and  performance 
prediction.  The  RADSIM  program  began  as  a  batch  job 
executed  on  an  IBM  360  computer.  This  original  program  was 
later  modified  and  installed  in  the  RADC  GE  635  computer. 

As  a  result  of  subsequent  contractural  efforts  the 
capabilities  of  the  program  were  expanded  to  include  an 
exoatmospher ic  chaff  model,  target  model,  propagation 
effects,  ECM,  and  more  advanced  waveform  phase  coding 
techniques.  In  addition,  the  operational  procedure  was 
changed  so  that  the  program  could  be  executed  as  a  remote 
batch  job  using  the  CARDIN  facility  available  under  GCOS 
Time  Sharing  System  (TSS).  The  internal  architecture  of 
RADSIM  remained  essentially  unchanged. 


In  using  RADSIM  on  the  R ADC  computer  it  was  noted  that 
the  most  time  consuming  aspect  of  a  simulation  was  the 
evaluation  of  the  results.  The  second  most  time  consuming 
aspect  was  the  preparation  of  RADSIM  Simulation  Input  Files 
<SIF's>.  To  help  alleviate  these  shortcomings  the 
Dedicated  User  Interface  Subsystem  (DUIS)  was  designed  and 
implemented.  The  DUIS  provides  a  good  on-line  plotting 
capability  for  supporting  RADSIM  and  other  GCOS  computer 
programs.  It  does  not,  however,  provide  sufficient  aid  to 
the  user  in  the  setup  of  simulation  jobs.  The  effort 
described  herein  was  directed  toward  the  implementation  of 
the  necessary  support  software  to  simplify  the  user's  task 
in  the  setup  of  radar  simulation  jobs.  The  effort 
documented  herein  is  the  final  stage  in  the  evolution  of 
the  radar  simulation  from  a  pure  batch  job  (RADSIM)  to  a 
highly  interactive  design  tool  (IRSS). 


SECTION  2 
SUMMARY 


This  report  documents  a  study  and  investigation 
directed  toward  modifying  the  Interactive  Radar  Simulation 
System  (IRSS)  controlling  software  structures  to  simplify 
the  user-IRSS  interface  functions.  In  performing  this 
effort  the  RADSIM  computer  program,  formerly  run  under 
remote  batch,  was  converted  for  execution  under 
time-sharing  in  a  truly  interactive  manner. 

In  performing  this  effort  only  the  controlling  software 
structure  was  modified.  The  characteristics  of  the 
simulation  modules  were  not  changed.  Therefore,  the  module 
descriptions  which  have  been  documented  in  an  earlier 
report  (Ref.  1)  are  still  valid.  In  addition,  the  Graphics 
Control  Subsystem  (GCS)  and  the  DUIS  were  unchanged  and 
also  have  been  documented  in  earlier  reports  (Ref.  2  &  3). 
In  this  report  the  information  considered  in  arriving  at  a 
modified  IRSS  design  is  discussed  in  Section  3.  In  Section 
4  the  current  configuration  of  the  IRSS  is  described. 

The  operational  procedure  for  the  IRSS  is  documented  in 
the  User's  Manual  which  is  contained  in  a  separate  volume. 
In  Appendices  A,  B,  and  C  of  this  report  examples  are 
provided  of  simulations  performed  using  the  IRSS.  These 
examples  were  chosen  to  illustrate:  interactive 

operation,  computer  directed  simulation  setup,  and 
operation  from  a  simulation  RUN  file.  Appendix  D  contains 
a  list  of  acronyms. 
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SECTION  3 
BACKGROUND 


3.1  GENERAL 

In  this  section  the  various  elements  of  background 
information  which  were  considered  in  arriving  at  the 
implemented  design  are  discussed.  First,  the  role  of 
models  in  system  design  is  discussed  and  the  stages  in  the 
design  process  where  simulation  is  cost  effective  are 
identified.  Second,  the  evolution  of  the  RADSIM  computer 
program  is  reviewed.  Third,  the  configuration  of  the  IRSS 
at  the  beginning  of  this  effort  is  described  and  its 
capabilities  and  weaknesses  are  evaluated.  Fourth, 
potential  improvements  are  described  which  would  have 
increased  the  utility  of  RADSIM. 


3.2  THE  ROLE  OF  MODELS  IN  SYSTEM  DESIGN 

The  process  of  designing  a  system  is  strongly 
dependent  on  the  use  of  models.  The  definition  of  model 
used  here  is  =  "an  abstract  object  which  descibes  or 
represents  a  physical  object”.  The  design  of  a  complex 
system  can  be  thought  of  as  the  successive  refinement  of  a 
model.  This  process  will  be  briefly  outlined  as  follows: 

1.  A  desired  operational  capability  is  defined.  This 
normally  consists  of  an  objective  and  a  set  of 
groundrules . 

2.  In  order  to  satisfy  this  capability  a  number  of 
possible  solutions  is  explored. 

3.  The  solutions  having  the  most  promise  are  defined 
in  more  detail  in  order  to  form  a  basis  for 
comparison. 

4.  By  comparing  the  models  of  competing  solutions  a 
conclusion  is  reached  as  to  which  is  the  preferred 
approach  to  satisfying  the  objective. 

5.  In  order  to  build  the  selected  system  the  model 
must  be  further  refined  to  break  it  down  into  its 
component  parts.  Ultimately,  a  set  of  detailed 
specifications  for  the  component  parts,  usually 


subsystems,  must  be  generated  so  that  they  can  be 
built  or  purchased. 


6.  Once  the  characteristics  of  the  component  parts  of 
the  system  have  been  defined  then  a  system  model  is 
built  from  the  bottom  up  and  system  performance 
estimated . 

7.  The  specif ications  of  the  subsystems  are  refined  as 
necessary  to  optimize  the  ratio  of  cost  ♦  risk  to 
performance . 

8.  Specifications  are  frozen  and  the  component  parts 
of  the  system  are  purchased  or  built. 

9.  An  experimental  model  of  the  system  is  configured, 
tests  are  performed,  and  the  subsystem 
specifications  are  refined  as  necessary. 

Depending  on  the  complexity  of  the  system  involved, 
various  steps  in  the  process  described  above  may  be 
omitted.  From  the  standpoint  of  minimizing  design  risk  the 
procedures  described  in  Steps  6  and  7  are  crucial.  In  the 
past  Step  6  often  has  been  nothing  more  than  the 
formalization  of  the  results  from  Step  S  in  the  form  of  a 
system  Accuracy  Control  Document  (or  performance  analysis). 
In  order  to  truly  minimize  risk,  the  evaluation  performed 
in  Step  6  should  be  an  independent  evaluation. 

Specifically,  it  should  be  a  detailed  model  which 
accurately  represents  the  internal  behavior  of  each 
subsystem.  These  refined  models  typically  have  involved 
either  mathematical  analysis  or  simulation. 

3.2.1  Mathematical  Analysis 

In  mathematical  analysis  the  goal  is  to  combine  the 
various  models  using  algebraic  techniques  and  arrive  at  a 
single  equation  or  set  of  equations  which  will  give  system 
performance  as  a  function  of  various  system  parameters. 
Providing  that  no  simplifying  assumptions,  approximations, 
etc.  are  made,  this  approach  will  lead  to  an  accurate 
estimate  of  system  performance.  Unfortunately,  radar 
systems  are  loaded  with  subsystems  which  make  life 
difficult  for  the  mathematical  analyst,  e.g.,  nonlinear 
effects  such  as  receiver  compression  and  saturation,  analog 
to  digital  converters,  and  digital  processor  arithmetic 
truncation.  In  addition,  the  usual  mathematical  analysis 
techniques  are  heavily  biased  toward  using  Gaussian 
d is t r ibu t ions  for  everything.  As  long  as  the  real  world 
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can  be  characterized  by  Gaussian  distributions, 
mathematical  analysis  solutions  are  obtainable  and 
sometimes  are  accurate  representations  of  the  system 
analyzed.  An  advantage  of  analysis  solutions  is  that  the 
resulting  equation  or  equations  can  be  solved  in  a 
straigh tforward  manner  to  produce  radar  system  performance 
curves . 


3.2.2  Simulation  Procedure 

In  obtaining  solutions  via  simulation  the  goal  is  to 
cause  a  digital  computer  or  some  special  purpose  simulation 
hardware  to  behave  in  the  manner  prescribed  by  the  various 
subsystem  models.  In  this  way  the  response  of  the  radar 
system  to  a  particular  environment  can  be  accurately 
predicted.  The  advantage  of  simulation  is  that  radar 
subsystems  can  be  accurately  modeled,  even  down  to  the  bit 
level  for  digital  signal  processors.  Empirical  data  can 
easily  be  used,  e.g.,  antenna  patterns,  receiver  transfer 
functions,  etc.  Simulation  procedures  are  not  biased 
toward  any  particular  probability  distribution.  Therefore, 
assumptions  about  Gaussian  statistics  are  unnecessary.  The 
use  of  simulation  and  the  interpretation  of  results  does 
not  require  the  mathematical  sophistication  which  is  needed 
to  successfully  produce  closed  form  mathematical  solutions. 
Simulation  does  have  the  disadvantage  that,  in  general,  it 
does  require  more  computer  time  than  the  evaluation  of 
closed  form  solutions  obtained  via  mathematical  analysis. 
This  is  especially  true  when  dealing  with  stochastic 
processes  for  which  one  desires  to  generate  statistics  that 
are  representative  of  an  entire  population.  It  should  be 
noted  that  typically  mathematical  analysis  requires  more 
manhours  than  does  the  setting  up  of  a  simulation  once  the 
simulation  software  has  been  developed. 


3.3  RADSIM  PROGRAM  STRUCTURE  EVOLUTION 

In  this  subsection  the  development  of  RADSIM  is 
discussed.  It  should  be  noted  that  this  description  of  the 
RADSIM  program  evolution  is  concerned  with  structural 
changes  that  effect  user  efficiency  and  perception  of 
RADSIM.  The  description  contained  herein  does  not  address 
itself  to  the  development  of  simulation  and  analysis 
modules  which  make  up  the  core  of  RADSIM.  These  modules 
are  virtually  independent  of  the  user  interface  structure. 
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RADSIM  began  as  a  batch  job  that  was  run  using  punch 
card  input  media  only.  In  setting  up  the  program 
Input/Output  (I/O)  structure  an  attempt  was  made  to 
minimize  the  amount  of  user  input  data  that  was  required. 
This  was  done  for  two  reasons.  First,  the  probability  of 
making  a  typographical  error  is  proportional  to  the  number 
of  characters  keypunched.  Second,  the  keypunching  of  cards 
is  a  tedious,  time  consuming  process  that  should  be 
minimized  if  possible.  Therefore,  a  rather  criptic 
simulation  command  structure  was  developed  using  a 
combination  of  simulation  control  words  (SCW)  and  module 
reference  numbers  (MRN).  In  this  way  only  nine  characters 
(SCW  =  6  CHAR  and  MRN  =  3  CHAR)  on  one  punch  card  were 
required  to  cause  execution  of  a  RADSIM  module. 

Minimization  of  the  number  of  characters  per  punch  card  as 
well  as  the  minimization  of  the  total  number  of  punch  cards 
was  the  primary  goal.  For  specifying  module  parameter  data 
NAMELIST  I/O  was  used  because  it  is  essentially 
self-documenting  since  parameter  names  are  paired  with 
their  values,  e.g.  entries  are  of  the  form: 

PARAM=1 0 . 0 , IFLG=i ,etc .  The  program  was  run  for  a  few  years 
in  this  form  on  both  GE  635  and  IBM  360  computer  systems. 

A  block  diagram  of  the  RADSIM-B  structure  and 
operating  procedure  is  shown  in  Figure  3-1.  In  this  figure 
the  user  is  shown  in  two  ways.  The  user  appears  3t  the  top 
as  an  operator  in  the  block  entitled,  "  User  Specification 
of  Problem."  The  user  also  appears  at  the  bottom  as  an 
analyst  in  the  block  entitled,  "User  Evaluation  of 
Results."  The  procedure  utilized  in  running  this  version 
of  RADSIM  is  as  follows:  First,  the  user  determines  the 

necessary  input  data  that  is  required  to  run  the  simulation 
model.  This  input  data  is  given  the  name  Simulation  Input 
File  (SIF).  Second,  the  SIF  is  keypunched.  Third,  this 
card  deck  is  combined  with  the  necessary  Job  Control 
Language  (JCL)  to  form  the  Job  Definition  File  (JDF)  and 
this  is  then  given  to  the  computer  operator  for  execution 
as  a  batch  job. 

Once  program  execution  begins,  the  SIF  is  processed  by 
the  input  processor  portion  of  the  program  which  takes  the 
input  data  and  converts  it  into  a  compact  form  for 
subsequent  use  by  the  simulation  and  analysis  modules.  The 
reason  for  doing  this  is  that  I/O  format  statements  for 
reading  in  the  user's  data  and  the  necessary  pre-processi ng 
of  that  data  require  approximately  20K  of  core.  In  order 
to  minimize  the  amount  of  core  required  to  run  a  simulation 
job  it  was  decided  to  separate  the  job  into  two  load 
modules.  In  this  procedure  the  total  JDF  is  processed  by 
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the  input  processor  and  the  output  is  placed  on  an 
intermediate  file.  A  listing  is  produced  of  all  the  user's 
input  data  plus  any  error  diagnostics. 

Next  the  simulation  and  analysis  load  module  is 
executed.  Its  input  data  is  from  the  intermediate  file 
loaded  by  the  input  processor.  It  also  can  make  use  of 
scratch  files.  All  of  the  output  data  from  the  simulation 
and  analysis  load  module  is  placed  on  an  output  file.  This 
output  file  is  subsequently  printed  on  a  line  printer  or 
used  in  an  off-line  plotter.  The  user  then  evaluates  the 
output  produced  by  the  simulation  and  determines  if  the 
desired  results  were  acheived  or  if  modifications  need  to 
be  made  and  another  job  run.  If  so,  this  path  is  shown  in 
the  figure  going  from  the  user  evaluation  back  up  to  the 
user  as  an  operator.  This  interactive  path  is  rather  long 
and  is  basically  done  on  a  job-by-job  basis.  Typically, 
the  length  of  time  required  between  the  submission  of  a  job 
and  the  evaluation  of  the  results  was  on  the  order  of  half 
a  day.-  It  should  be  noted  in  this  figure  that  both  the 
input  processor  and  the  simulation  and  analysis  load 
modules  were  executed  as  batch  jobs.  Also  all  files 
generated  were  temporary  files,  i.e.,  they  were  purged  from 
the  system  as  soon  as  the  batch  job  was  completed. 
Therefore,  all  input  data  and  output  data  existed  only  as 
punch  cards,  paper  listings,  or  plots. 

After  the  time  sharing  capability  of  the  GE  635  had 
sufficiently  matured,  it  was  decided  to  try  converting 
RADSIM  from  a  pure  batch  processing  mode  to  remote  batch 
execution.  The  initial  goals  were  to  avoid  having  to 
handle  boxes  of  punch  cards  and  to  allow  program  check  out 
and  debugging  to  be  done  from  remote  terminals. 

Preliminary  results  were  good  and  therefore  the  whole 
RADSIM  program  was  put  on  permanent  disc  storage  (PRMFL)  in 
the  GE  635  at  RADC.  Since  then  all  access  to,  modification 
of,  and  use  of  RADSIM  was  done  via  time  share  <TSS>. 
Initially,  the  program  structure  remained  the  same  as  it 
was  in  batch  processing.  Then  some  modifications  were  made 
to  minimize  the  size  of  printouts  (reduce  job  output  to  an 
absolute  minimum).  This  was  desirable  since  most  remote 
terminals  at  that  time  operated  at  30  characters  per  second 
or  less.  Therefore,  printing  long  listings  was  time 
consuming.  In  batch  jobs  (the  old  way)  the  output  was 
produced  on  a  line  printer  and  therefore  one  worried  little 
about  compactness.  The  initial  approach  to  input  was  still 
good  since  it  minimized  connect  time  to  the  host  computer 
and  the  amount  of  typing  required  of  the  user.  Therefore 
there  was  no  attempt  to  modify  it.  The  biggest  problem  was 
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to  efficiently  prepare  simulation  output  data  for 
evaluation  by  the  user.  The  procedure  for  obtaining  plots 
of  the  output  data  was  time  consuming  since  it  involved 
punching  plot  data  on  cards  and  subsequently  plotting  the 
data  on  an  HP9820  desk  calculator. 

A  block  diagram  of  RADSIM-C  is  shown  in  Figure  3-2. 

In  this  figure  the  GE  635  text  editor  replaces  the  keypunch 
operator.  The  user  now  creates  his  JDF  by  using  the  text 
editor.  When  he  is  ready  to  run  a  job,  the  JDF  is 
submitted  to  the  batch  processor  via  the  remote  batch 
system  (CARDIN) . 

Functionally,  the  input  processor  operates  in  the  same 
manner  as  before,  that  is,  the  SIF  is  read  in,  processed, 
and  an  intermediate  file  generated.  It  differs  in  that 
instead  of  directly  producing  a  listing  its  output  goes 
into  a  JOUT  file  so  that  the  user  can  subsequently  look  at 
it  via  a  remote  terminal,  if  desired.  After  the  input 
processor  load  module  has  completed  its  processing  the 
simulation  and  analysis  load  module  is  loaded  and  executed. 
The  input  data  for  this  load  module  is  the  intermediate 
file  generated  by  the  previous  execution  of  the  input 
processor.  The  simulation  output  data  is  written  to  a 
PRMFL  which  was  allocated  by  the  user.  The  system  output 
is  again  written  to  a  JOUT  file  for  subsequent  access  by 
the  user  from  a  remote  terminal.  The  output  data  files 
can,  at  the  option  of  the  user,  either  be  punched  on  card 
decks  or  listed.  The  data  punched  on  card  decks  normally 
was  used  to  generate  plots  on  an  HP  desk  calculator.  The 
user  had  the  option  of  determining  the  plot  axis  scales 
that  were  used  in  making  the  plots,  and  therefore,  had  some 
control  over  the  data  that  was  plotted  independent  of  the 
execution  of  RADSIM.  It  should  be  noted  that  the  output 
data  file  and  the  JDF  were  both  stored  in  PRMFL's,  and 
therefore,  remain  in  the  system  permanently  until  purged  by 
the  user.  The  intermediate  file  and  the  scratch  files  were 
still  temporary  and  existed  only  as  long  as  the  batch  job 
was  resident  in  the  machine.  The  user  is  still  shown  at 
the  bottom  as  an  analyst  evaluating  the  output  data.  Based 
on  his  decisions,  he  could  make  changes  to  his 
specification  of  the  problem  and  rerun  the  job. 
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In  this  case,  the  turnaround  time  from  submission  of  a  1 

job  to  its  output  was  on  the  order  of  30  minutes  or  less.  > 

The  big  problem  with  this  technique  was  the  time  delay 
involved  in  getting  cards  punched  and  transporting  then  to 
the  desk  calculator  for  plotting.  Even  though  the 
execution  of  the  RADSIM  program  had  been  significantly 
improved  the  overall  system  performance  was  still  rather 
poor  requiring  roughly  two  hours  per  job  if  plots  were 
desired . 

This  problem  of  efficiently  presenting  simulation 
output  data  to  the  user  was  studied  and  the  conclusion 
reached  was  that  a  remote  job  entry  processor  was  needed 
which  had  a  plotting  and  hardcopy  generation  capability. 

Subsequently,  the  DUIS  was  designed,  developed,  and 
integrated  with  RADSIM.  The  combination  of  the  DUIS  and 
RADSIM  was  referred  to  as  the  Interactive  Radar  System 
Simulation  System  <IRSS)  and  is  discussed  further  in  the 
next  subsection. 
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3.4  INITIAL  IRSS  CONFIGURATION 

In  this  subsection  a  description  is  provided  of  the 
IRSS  as  it  existed  when  the  effort  documented  herein  was 
initiated.  During  development  of  this  system  emphasis  was 
placed  on  the  efficient  production  of  plots  from  simulation 
results.  The  secondary  goal  was  to  improve  the  input  side 
of  RADSIM  by  providing  DUIS  resident  look-up  tables  for  the 
user.  This,  however,  was  found  not  to  be  feasible  for  a 
system  which  did  not  have  a  disc  drive  for  storing  the 
large  amounts  of  reference  data  needed.  Therefore,  this 
effort  was  successful  mainly  in  improving  the  output  side 
of  RADSIM. 

In  Figure  3-3  the  block  diagram  is  shown  of  the  IRSS 
which  resulted  from  adding  the  DUIS  to  RADSIM.  The  program 
is  still  executed  as  a  batch  job.  The  software  which  makes 
up  the  RADSIM  program  itself  is  the  same  in  this  figure  as 
in  the  previous  figure.  In  this  diagram  the  primary  user 
data  entry  device  and  also  data  retrival  device,  is  a 
Tektronix  4014  graphics  display.  This  display  is  used  to 
input  the  data  to  the  DUIS  input  processor  which  in  turn 
prepares  the  job  input  files  for  the  RADSIM  program.  This 
input  process  can  be  executed  as  a  stand  alone  program  in 
the  DUIS,  or  can  be  used  in  conjunction  with  the  editing 
capabilities  of  the  H6180.  On  the  output  side  of  the 
simulation,  the  output  file  is  accessed  by  the  DUIS  through 
an  output  processor  which  is  resident  in  the  H6180. 

The  output  processor  and  the  DUIS  graphics  control 
processor  work  together  in  order  to  transfer  data  from  an 
output  file,  loaded  by  a  simulation,  to  the  DUIS  for 
subsequent  plotting.  The  program  can  transfer  data  from 
the  H6180,  immediately  plot  it,  and  produce  hard  copies  if 
desired  by  the  user.  One  of  the  requirements  in  developing 
the  DUIS  was  that  the  RADSIM  I/O  structure  could  not  be 
changed.  This  was  done  to  ensure  that  the  program  could  be 
run  from  any  remote  terminal. 

3.4.1  RADSIM  Computer  Program 

In  this  paragraph  the  RADSIM  computer  program  is 
discussed  with  emphasis  on  the  program  architecture  and 
user  input  data  requirements. 

3 . 4 . 1 . 1  RADSIM  Architecture 

The  RADSIM  computer  program  was  divided  into  two 
segments  which  were  executed  as  separate  load  modules  in 
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Job  by  Job 


the  H6180.  The  first  segment  processed  the  Simulation 
Input  File  (SIF)  that  defined  the  simulation  to  be 
performed.  This  preprocessing  consisted  of  generating  a 
Simulation  Module  Execution  Sequence  Table  <SMEST>  and 
placing  data  in  the  Module  Parameter  Table  <MPT>  and  in  the 
Module  Array  Table  <MAT>.  The  contents  of  the  3MEST,  MPT, 
and  MAT  were  stored  on  a  temporary  file  for  subsequent  use 
by  the  simulation  segment.  In  addition,  the  clutter  model 
initialization  was  performed  if  the  clutter  model  was  to  be 
used  in  the  simulation. 

The  second  segment  performed  the  actual  simulation. 

The  selection  and  order  of  execution  of  the  simulation 
modules  was  determined  by  the  SMEST.  Each  combination  of 
simulation  module  and  waveform  storage  assignment  was 
specified  by  a  Module  Reference  Number  (MRN).  The 
available  waveform  storage  areas  were  designated  by  the 
symbolic  names  XT,  YT,  XA,  and  XB.  These  waveform  storage 
arrays  were  core  resident  which  severely  limited  the 
expansion  potential  of  the  program.  For  any  module  if  more 
than  one  combination  of  waveform  storage  assignment  was 
desired  then  additional  MRN'S  were  assigned. 

Both  activities  of  RADSIM  were  core  resident.  The 
load  module  for  the  second  segment  required  approximately 
70K  of  memory.  This  large  load  module  size  resulted  from 
the  fact  that  all  simulation  modules  to  be  used  in 
performing  a  job  were  loaded  into  core  and  remained  there 
throughout  the  simulation  even  though  only  one  at  a  time 
was  actually  being  used. 

3 . 4 . 1 . 2  GCOS  Job  Definition  File 

In  order  to  define  a  GCOS  batch  job  one  must 
communicate  with  GCOS  via  control  cards.  The  set  of  GCOS 
control  cards  and  simulation  input  data  are  collectively 
referred  to  as  the  Job  Definition  File  (JDF).  An  example 
of  a  JDF  is  shown  in  Figure  3-4.  The  user  provided  SIF 
processed  by  the  first  segment  is  shown  following  the  DATA 
card.  This  input  data  will  be  discussed  further  in 
paragraph  3.4. 1.3.  It  should  be  noted  that  most  of  the 
cards  which  make  up  the  JDF  are  required  to  define  the  load 
module.  The  only  cards  which  were  truly  dependent  on  the 
user  are  the  IDENT  card  which  identifies  the  user  to  the 
operating  system  and  the  PRMFL  card(s)  to  be  used  in 
storing  plot  data.  Through  the  use  of  SELECT  cards  the 
user  could,  to  some  extent,  tailor  the  simulation  so  that 
only  those  modules  he  required  were  included  in  the  load 
module. 


20S  :  I DENT :  BECAV UO 1  .R4NCOOC  ,65121  1040063 , JOBNAM 
303  :  OPTION  :  FORTRAN 

405  :  S ELECT :  liKO A  V UO 1  /M  \  1  NP .Hl/OLODRI  X 
DOS  :  SELECT :  BEC.A  \,  UO  1  /  SUPORT3 JR/OSUPRT  1 
60S  :  SELECT  :  BECAVUO 1  /'SUBSYSS.JR/'OPIIENC 
70S : SELECT : BECAVUO 1 /ENVRS  JR/OCLl NT 
80S  :  SELECT :  BECAVUO  1  /SUPOllTS  JR/OARS  1 N 
90S : EXECUTE 

1 OOS : LIMITS : 10, 30K.0.5K 
1 1 OS : F ! LE : 02 , X 1 S , 10R 
120S : F I LE : 1 1 .X2S.10R 
1 BOS : DATA : 05 


Simulation 

Input 

File 


470S t OPT I  on : FORTRAN 

4 80S : SELECT : BECAVUO 1 SKA  I NSSJR/OS 1 MEX 
4  90S : SELECT : BECAVUO I ^SUPORl'SJR/OPLOTS 
500S : SELECT : BECAVUO 1 /SUPORTS JR/0SUFRT1 
5 1  OS  :  SELECT :  BECAVUO  1  .'SUPORTS  JR/0M1  SC  1 
520S : SELECT : BECAVUO 1 /SUPORTSJR/OMI SC2 
53CS : SELECT : BECAVUO 1 -'SUPORTS  JR.'0SUFRT2 
540S : SELECT : BECAVUO 1 /SUPORTS JR/OZFFT 
550S  : SELECT:  BECAVUO  1  /SUPORTSJFt'OARS IN 
5 60S : SELECT : BECAVUO 1 /SUBSYSS JR/OXMTR 
570S : SELECT : BEC  AVUO 1 /SUBSYSS JR/ODF I N 
5 SOS  :  SELECT :  BECAVUO  1  /'ENYRSJR/OTGCL 
590S : EXECUTE 
600S : LIMITS: 1 0 , 65K ,0 ,20K 

6 1 OS : PRUFL : 04 , R/W , L , BECAVUO 1 /DSTORS JR/F I LEI 
620S : F I LE :02 ,X1R , 10R 
6308 : FILE : 1 1 ,X2R, 10R 
6408 : ENDJOB 


igure  3-  4  Example  of  a  GCOS  Job  Definition  File 


3 . 4 . i . 3  Simulation  Input  File 

The  RADSIM  SIF  contains  the  simulation  control  and 
module  parameter  data.  The  simulation  control  cards 
determine  which  simulation  modules  are  used  and  their  order 
of  execution.  Each  module  has  its  own  unique  MRN  or  set  of 
MRN's.  Multiple  MRN's  are  assigned  to  a  module  if  more 
than  one  assignment  of  input  and  output  waveform  storage  is 
required.  For  example,  the  module  XYTODB  has  two  MRN's: 

104  and  108.  If  MRN  =  104  is  selected  then  the  arrays  XT 
and  YT  are  processed  and  the  result  placed  in  XA.  If  MRN  = 
108  is  selected  then  the  same  input  arrays  are  processed 
but  the  result  is  placed  in  the  array  XT. 

The  specification  of  the  input  data  for  a  module  is 
done  via  namelist  data  card(s)  which  follow  the  simulation 
control  card  that  selected  the  module. 

3.4.2  IRSS  WEAKNESSES 

In  this  subsection  the  various  weaknesses  in  the  IRSS 
are  discussed.  These  are  grouped  into  three  categories: 
Operational  or  general,  DUIS,  and  RADSIM  problems. 

3 . 4 . 2 . 1  Operational  Problems 

In  order  to  run  a  RADSIM  job,  a  JDF  was  set  up  which 
contained  a  large  number  of  GCOS  control  cards.  For  small 
simulation  jobs  the  control  cards  actually  outnumbered  the 
SIF  cards.  This,  therefore,  represented  an  overhead  task 
that  the  user  must  perform  which  was  not  directly  related 
to  radar  system  design.  Because  the  RADSIM  computer 
program  was  executed  under  remote  batch  there  was  no 
mechanism  whereby  an  error  made  by  the  user  could  be 
corrected  in  a  timely  manner.  For  a  batch  job  the  only 
recourse  when  an  error  was  detected  was  to  print  some 
diagnostic  for  the  user  and  abort  the  job.  Through  CARDIN 
each  job  normally  required  up  to  30  minutes  or  so  to  run. 
This  means  the  turnaround  time  on  each  user  error  was  quite 
long.  In  setting  up  a  simulation  job  the  user  must  specify 
the  data  parameters  required  by  each  module  to  be  executed. 
These  parameters  were  identified  via  FORTRAN  symbolic  names 
in  the  namelist  data  cards.  The  problem  was  that  users 
often  had  difficulty  relating  these  symbolic  names  to 
corresponding  radar  subsystem  parameters.  This  parameter 
identification  problem  was  to  some  extent  alleviated 
through  the  use  of  module  cross  reference  tables  and 
parameter  tables.  These  tables,  however,  were  rather  large 
and  time  consuming  to  use. 
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3. 4. 2. 2  PUIS  Problems 

The  DUIS  as  currently  configured  uses  paper  tape  for 
peripheral  storage.  This  has  a  number  of  drawbacks.  One, 
paper  tape  is  not  a  reusable  media  form  and  therefore  is 
quite  expensive.  Two,  I/O  transfers  with  paper  tape  are 
relatively  slow,  i.e.  75  characters  per  second  for  output 
and  300  characters  per  second  for  input.  Three,  paper  tape 
is  not  very  reliable. 

The  HP  2108A  minicomputer  used  in  the  DUIS  is 
configured  with  32K  words  of  memory  which  is  the  maximum 
amount  of  memory  that  can  be  addressed  without  the  use  of 
mapping.  Fortunately,  all  application  programs  developed 
to  date,  except  the  block  diagram  generator ( BLDIAG) ,  easily 
fit  into  the  available  memory. 

The  DUIS  cannot  support  software  development  using 
FORTRAN  IV  since  the  FORTRAN  IV  compiler  requires  the  use 
of  a  disc  drive.  This  restriction  to  FORTRAN  II  places  an 
additional  burden  on  the  programmer.  Also,  the  FORTRAN  II 
compiler  does  not  make  the  most  efficient  use  of  available 
memory . 

The  goal  of  the  BLDIAG  program  was  to  provide  the  user 
with  an  aid  in  the  setup  of  the  RADSIM  jobs,  specifically 
the  automatic  generation  of  the  SIF.  The  BLDIAG  program 
fell  short  of  this  goal  for  two  reasons:  One,  the  software 
required  to  properly  do  the  job  could  not  be  "crammed"  into 
the  HP2108A.  Two,  an  associated  problem  is  that  no  disc 
storage  was  available  and  therefore  the  RADSIM  cross 
reference  tables  and  module  parameter  tables  had  to  be 
restricted  in  size  so  that  they  could  be  stored  in  the 
computer  main  memory. 

3 . 4 . 2 . 3  RADSIM  Problems 

Probably  the  biggest  problem  with  RADSIM  was  that 
there  was  no  mechanism  for  the  user  to  correct  his  mistakes 
in  a  timely  manner.  Any  error,  no  matter  how  minor,  could 
ruin  a  simulation  job. 

The  RADSIM  program  used  an  architecture  which  allowed 
the  user  to  select  only  certain  prestructured  argument  list 
combinations  for  each  module.  The  user  communicated  his 
selection  of  module/storage  list  through  the  use  of  MRN's. 
This  made  the  job  setup  difficult  for  the  user  because  he 
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must  reference  a  table  to  find  out  what  the  various  numbers 
mean . 


The  RADSIM  program  was  structured  such  that  the  whole 
load  module  was  resident  in  core  during  the  simulation 
activity.  This  resulted  in  a  rather  large  load  module. 
Because  the  waveform  storage  arrays  were  core  resident  the 
user  was  severely  restricted  on  the  length  of  the  waveforms 
to  be  processed  and  the  number  of  waveforms  which  could  be 
used  in  a  simulation. 

3.4.3  POTENTIAL  IMPROVEMENTS 

In  this  subsection  various  ideas  are  described  that 
were  considered  in  order  to  improve  the  usefulness  of  the 
IRSS. 

3 . 4 . 3 . 1  Operational  Chanoes 

From  an  operational  standpoint  the  biggest  problem 
faced  by  the  user  is  remembering  the  meaning  of  various 
symbolic  names,  the  I/O  characteristics  of  the  modules, 
input  data  requirements,  etc.  To  alleviate  this  problem 
all  of  the  RADSIM  reference  material  should  be  incorporated 
into  a  data  base  which  is  disc  resident.  This  data  base 
should  be  easily  accessable  by  the  user  from  a  terminal. 
Another  potential  operational  change  is  the  elimination  of 
all  of  the  GCOS  control  cards  which  must  be  prepared  by  the 
user . 

3. 4. 3. 2  PUIS  Changes 

The  major  problems  with  the  DUIS  are  related  to 
hardware,  mainly  the  dependency  on  paper  tape.  The 
addition  of  flexible  disc  drives  to  the  DUIS  would  provide 
an  efficient,  reliable  means  of  storing  and  retrieving 
data.  A  secondary  problem  is  the  limited  memory  of  the 
DUIS  computer.  To  alleviate  this  at  least  32K  more  memory 
and  a  dynamic  mapping  capability  could  be  added.  In 
addition,  the  DUIS  operating  system  could  be  upgraded  to 
make  maximum  benefit  of  the  disc  drives  and  memory  mapping. 
Unfortunately,  none  of  the  recommended  changes  for  the  DUIS 
were  funded  under  the  effort  documented  in  this  report. 

3. 4. 3. 3  RADSIM  Chances 

Various  aspects  of  the  RADSIM  computer  program  are 
"carry-overs"  from  its  origin  as  a  batch  job.  The 
following  changes  could  be  made  to  improve  the  usefulness 


of  the  RADSIM  program: 

1.  Convert  the  simulation  activity  to 

a  link  overlay  to  reduce  the  load  module  size 

2.  Store  the  RADSIM  load  module  on  a 
disc  file  and  make  it  accessible  to 
any  user  via  TSS 

3.  Modify  the  technique  for  specifying 
modules  so  that  module  names  rather 
than  numbers  <MRN's>  are  used. 

Also ,  the  module  I/O  linkage  should  be  directly 
specified  in  terms  of  array  symbolic 
names . 

4.  Replace  the  data  preprocessing  activity 
with  an  interactive  procedure. 

5.  Modify  RADSIM  so  that  waveforms 
are  disc  resident  rather  than  core 
resident.  This  will  provide  the  user 
with  more  flexibility  and  reduce 

the  load  module  size. 
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SECTION  4 


I  R  S  S  DESCRIPTION 


4.1  GENERAL 

In  designing  any  tool  it  is  difficult  to  compromise 
between  the  desires  and  capabilities  of  the  novice, 
occasional,  and  experienced  users.  The  novice  must  be 
guided  through  the  procedure  in  order  to  familiarize  him 
with  it.  The  occasional  user  has  a  good  idea  of  what  he 
wants  to  do  but  can't  remember  exactly  how  to  go  about  it. 
He  therefore  may  commit  some  procedural  error.  The 
experienced  user  desires  complete  flexibility. 


In  modifying  the  IRSS  two  operati 
implemented:  user  directed  and  comput 

user  directed  mode  the  user  has  total 
can  combine  modules  in  any  way  he  sees 
simulation.  This  mode  was  intended  fo 
experienced  and  occasional  user  only, 
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In  this  section  the  structure  of  the  IRSS,  the  control 
flow,  and  the  subsystems  which  form  the  IRSS  are  discussed. 


4 . 2  STRUCTURAL  DESCRIPTION 

The  structural  block  diagram  of  the  IRSS  is  shown  in 
Figure  4-1.  In  this  figure  PRMFL  is  used  to  indicate 
permanent  storage  of  data  on  disc.  SYS  indicates  that 
temporary  storage  is  obtained  from  the  operating  system. 

TSS  indicates  that  a  subsystem  is  executed  under  H6180  TSS 
YFORT .  The  structure  of  the  IRSS  has  been  divided  into 
three  processes.  The  input  process  consists  of  selecting  a 
module  for  execution  and  providing  the  necessary  input 
data.  The  simulation  process  consists  of  executing  the 
appropriate  simulation  module.  The  output  process  involves 
generating  plots  of  simulated  waveforms. 

In  the  input  process  the  Interactive  Translator 
Subsystem  <ITS)  is  used  to  process  user  commands  and  to 
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prepare  all  information  required  to  execute  a  simulation 
module.  The  ITS  can  access  the  RADSIM  data  base  in  order 
to  provide  information  to  the  user.  The  user  communicates 
with  the  ITS  on  a  line  by  line  basis.  If  the  user  makes  an 
error  it  is  immediately  brought  to  his  attention.  A 
conversation  monitor  feature  is  incorporated  so  that  a 
permanent  copy  of  the  user's  transactions  with  the  computer 
can  be  generated.  The  RADSIM  data  base  and  the  ITS  are 
resident  in  the  H6180.  A  facility  has  been  provided  such 
that  the  user  commands  and  parameter  specifications  can  be 
stored  in  a  SRF.  In  that  way  a  permanent  copy  of  these 
inputs  can  be  created  for  use  at  a  later  time. 

In  the  simulation  process  the  Waveform  Processing 
Section  (WPS)  is  structured  as  a  link  overlay  and  is 
resident  in  a  PRMFL.  The  waveforms  are  resident  in  disc 
files  also.  The  required  memory  for  the  load  module  is  34K. 
This  small  load  module  size  has  significantly  improved  job 
turnaround  time  and  has  reduced  job  costs.  The  Multiple 
Pass  File  (MPF)  capability  allows  a  simulation  procedure  to 
be  rerun  with  simple  parameter  changes  in  order  that 
parameter  sensitivity  analyses  can  easily  be  performed. 

In  the  output  process  plot  data  are  passed  to  the 
Graphic  Control  Subsystem  (GCS)  for  plotting.  The  user  can 
replot  data  on  line  and  make  hard  copies  as  required.  This 
portion  of  the  IRSS  is  essentially  unchanged  from  the 
previous  version. 


4.3  OPERATIONAL  DESCRIPTION 

The  main  consideration  in  modifying  the  IRSS  was  to 
minimize  or  otherwise  simplify  the  inputs  required  from  the 
user.  To  this  end  no  GCOS  control  cards  must  be  prepared 
since  batch  processing  has  been  eliminated.  The  input 
requirements  were  simplified  by  implementing  computer  aids 
in  job  setup,  a  computer  resident  data  base,  and  several 
levels  of  error  checking. 

4.3.1  Job  Setup  Procedures 

In  this  paragraph  the  two  procedures  for  setting  up 
simulation  jobs  are  described.  All  of  the  procedures  are 
designed  to  rely  heavily  on  information  contained  in  the 
RADSIM  data  base. 
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Under  this  procedure  the  user  is  in  control.  He  tells 
the  computer  which  modules  are  to  be  executed,  their 
parameters,  the  order  of  execution,  and  their  I/O  lists. 
When  operating  under  this  procedure  the  simulation  is 
performed  in  a  totally  interactive  manner.  As  the  user 
specifies  each  module  it  is  executed  and  the  resulting 
output  can  be  immediately  plotted  at  the  user's  option. 

All  user  I/O  is  handled  through  the  ITS  which  performs 
error  checking  and  provides  for  creation  of  SRF's  or 
execution  from  them.  During  this  procedure  the  execution 
sequence  of  the  modules  is  checked  to  ensure  that  the 
required  system  level  setup  modules  were  previously 
executed  as  required.  In  Appendix  A  of  this  report  an 
example  is  provided  of  interactive  execution  of  the  IRSS. 

4.3. 1.2  Computer  Directed  Job  Setup 

Under  this  procedure  the  computer  is  in  control.  The 
user  is  led  through  a  logical  sequence  of  decision  steps 
such  that  the  general  characteristics  of  the  desired 
simulation  are  defined.  Once  these  general  characteristics 
are  identified  the  user  is  led  through  a  more  detailed 
sequence  which  results  in  identification  of  the  specific 
modules  to  be  used  in  setting  up  a  simulation.  Finally, 
the  input  parameters  for  each  module  are  requested  and  a 
SRF  is  created.  There  are  two  phases  to  this  procedure.  In 
Phase  I  block  diagrams  and  a  question/answer  sequence  are 
used  in  setting  up  the  SMEST.  In  Phase  II  a 
question/answer  sequence  is  used  to  define  the  parameters 
of  the  modules  entered  into  the  SMEST.  In  Appendix  B  of 
this  report  an  example  is  provided  which  illustrates  the 
use  of  the  User  Aid  Processor  <UAP>. 


In  Phase  I  a  prototype  radar  system  block  diagram  is 
drawn  which  contains  only  major  subsystems,  e.g.  antenna, 
environment,  transmitter,  receiver,  etc.  The  user  is  then 
asked  to  pick  those  which  he  wishes  to  incorporate  into  his 
simulation.  Once  the  user  has  chosen  the  subsystems,  a 
refinement  subphase  is  entered  wherein  a  detailed 
mechanization  block  diagram  is  presented  for  each 
subsystem.  The  user  is  again  asked  to  choose  blocks  from 
those  available.  After  the  simulation  has  been  defined  the 
user  is  allowed  to  insert  plots  where  he  desires.  Also,  a 
MPF  can  be  defined  at  this  time.  The  final  result  of  this 
procedure  is  a  SMEST  which  is  subsequently  processed  in 
Phase  II. 


In  Phase  II  the  IFE  processor  is  used  to  obtain  module 
parameters  from  the  user.  Error  checking  is  performed  on 
all  user  inputs.  The  output  from  this  phase  is  a  SRF  which 
can  be  run  by  using  the  IRSS  command  <RUN>. 

4.3.2  Error  Checking  and  Recovery 

An  essential  component  of  the  modified  IRSS  is  an 
extensive  error  checking  facility.  There  are  three  levels 
of  error  checking  which  are  discussed  further  in  the 
following  paragraphs.  Whenever  an  error  is  detected, 
recovery  procedures  are  invoked  to  explain  the  error  to  the 
user  and  allow  him  to  correct  his  mistake  and  recover  from 
the  error.  Specific  examples  of  error  detection  are 
provided  in  the  user's  manual. 

4.3.2. i  General  Suntax  Errors 


Errors  in  this  category  consist  of  specifying  input 
data  in  an  improper  way.  This  includes  alphabetic 
characters  in  numeric  fields,  two  decimal  points  in  a 
field,  and  failure  to  put  a  decimal  point  in  a  real  field. 
These  errors  are  relatively  easy  to  correct  since  they  only 
involve  retyping  a  single  line  of  input. 

4. 3. 2. 2  Parameter  Ualue  Errors 


Errors  in  this  category  can  result  in  several  ways. 
One,  a  parameter  value  is  outside  the  acceptable  range, 
e.g.  specifying  the  pulse  width  as  a  negative  number.  Tw 
a  combination  of  parameters  produces  a  condition  that 
cannot  be  handled,  e.g.  in  FGENXY  the  combination  of  SPW, 
NSUBP,  and  FS  could  require  more  data  samples  than  can  be 
handled.  Third,  the  user  types  an  unrecognized  symbolic 
name  in  response  to  a  command  request  or  module  name 
request . 


4. 3. 2. 3  Module  Execution  Se 
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Errors  in  this  category  result  when  the  user  attempts 
to  execute  modules  in  an  unmeaningful  way.  This  can  result 
from  several  conditions.  One,  failure  to  initialize  a 
subsystem  before  using  it,  e.g.  not  initializing  the 
clutter  model  before  trying  to  use  it.  Two,  attempting  to 
process  a  waveform  array  that  has  not  been  initialized, 
i.e.  empty. 
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4.3.3  General  Information  Retrieval 


This  procedure  can  be  entered  by  the  user  at  the 
command  level  simply  by  typing  "HELP".  Once  the  user  has 
entered  this  procedure  he  can  retrieve  information  from  the 
RADSIM  data  base  just  by  typing  the  name  of  the  item  he 
would  like  to  know  more  about. 


4.4  CONTROL  FLOW 

In  Figure  4-2  a  block  diagram  is  shown  which 
illustrates  how  program  control  flow  is  modified  by  use  of 
the  IRSS  command  words.  In  the  figure  each  subsystem  of 
the  IRSS  is  shown.  All  switches  in  the  figure  are  shown  in 
the  position  which  they  have  when  the  IRSS  is  started. 

Next  to  each  switch  the  IRSS  command  words  are  shown  which 
cause  the  switch  to  change  position.  The  user  is  shown  on 
the  left  as  a  source  of  commands  and  input  data  and  on  the 
right  as  a  sponge  to  absorb  the  output  data  produced  by  the 
IRSS.  Arrows  are  used  to  indicate  the  data  flow  direction 
where  it  is  unidirectional. 

At  startup  the  IRSS  is  in  interactive  mode  with  no 
files  open.  The  user/terminal  keyboard  is  connected 
directly  to  the  ITS  which  passes  processed  information  to 
the  WPS.  If  the  user  types  in  a  module  name  the  ITS 
responds  by  asking  for  all  input  data  required  by  the 
module.  When  the  ITS  has  collected  all  required  input  data 
it  passes  this  information  to  the  WPS  which  loads  and 
executes  the  module  requested  by  the  user.  If  the 
requested  module  is  a  plotter  type  module  then  the  WPS 
connects  to  the  GCS  to  produce  a  plot  of  the  waveform 
specified  by  the  user. 

To  retrieve  information  from  the  data  base  the  command 
HELP  is  used.  When  this  occurs  SW#2  changes  position  and 
the  user/keyboard  is  connected  to  the  HELP  processor.  All 
subsequent  user  requests  are  routed  to  the  HELP  processor 
until  DONE  is  entered  which  resets  SW*2. 

To  create  a  RUN  file  from  interactive  execution  the 
command  OPENR  is  used.  This  causes  SW#3  to  close.  All 
subsequent  information  entered  by  the  user  is  stored  in  the 
RUN  file  until  a  CLOSER  command  is  entered  which  resets 
SW#3 . 
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To  run  a  simulation  from  an  existing  RUN  file  the 
command  RUN  is  used.  This  causes  SW#1  to  change  position 
and  the  ITS  is  connected  directly  to  the  input  RUN  file. 

The  user  is  required  to  provide  input  information  only  when 
plots  are  generated.  When  a  CLOSER  command  is  read  from 
the  input  RUN  file  or  an  EOF  is  detected  then  SW*i  is  reset 
to  its  normal  position. 

In  order  to  create  a  Multiple  Pass  File  <MPF)  the 
command  BGLOOP  is  used  to  close  SW#4.  All  subsequent 
module  execution  requests  and  their  associated  input 
parameters  are  stored  in  the  MPF.  The  ENLOOP  command  is 
used  to  close  the  MPF  and  reset  SW44.  If  the  MPF  is  to  be 
modified  then  the  MODIFY  command  is  used  to  close  the  SW#4 
to  allow  the  user  to  change  the  parameters  of  a  module.  To 
run  a  simulation  from  the  MPF  the  RUN  MPF  command  is  used 
to  change  the  position  of  SW#6.  The  WPS  now  receives  all 
module  execution  requests  and  module  parameters  from  the 
MPF.  SWt6  is  reset  when  an  EOF  is  detected  in  the  MPF. 

The  module  execution  list  contained  within  the  MPF  can  be 
printed  by  entering  the  command  DMP  MPF.  This  causes  SW#7 
to  change  position  to  allow  data  to  pass  to  the  display 
terminal  until  an  EOF  is  detected  in  the  MPF. 

To  create  a  SRF  using  the  User  Aid  Processor  the 
command  RUN  UAP  is  used.  This  causes  SW#5  to  change 
position  and  the  UAP  is  connected  directly  to  the  ITS.  The 
UAP  uses  the  Block  Diagram  Subsystem  (BDS)  to  create  block 
diagrams  via  the  GCS.  The  output  data  from  the  UAP  is 
placed  in  a  SRF.  SW#5  is  reset  when  the  user  indicates  he 
is  finished. 


4.5  SUBSYSTEM  DESCRIPTIONS 

In  this  subsection  the  new  subsystems  which  were 
developed  under  this  effort  are  discussed.  Those 
subsystems  which  were  not  changed  during  this  effort  are 
the  GCS,  BDS,  and  the  simulation  modules  which  are  used  in 
the  WPS. 

4.5.1  INTERACTIVE  TRANSLATOR  SUBSYSTEM 

The  ITS  is  composed  of  the  Interactive  Front  End 
processor  and  the  RADSIM  data  base.  Each  of  these  will  be 
discussed  in  more  detail  in  the  following  paragraphs. 


4.5.1. 1  Interactive  Front  End  <IFE) 

The  IFE  subsystem  is  designed  to  serve  as  an  interface 
between  an  application  program  and  the  user.  The  IFE  has 
access  to  a  data  base  which  can  be  used  to  assist  the  user. 
The  data  base  depends  on  the  application  program.  In 
Figure  4-3  a  functional  block  diagram  is  shown  of  the  IFE 
subsystem  attached  to  an  application  program.  In  this 
figure  the  application  program  data  base  is  contained  in 
the  IFE  file  which  is  disc  resident.  The  IFE  multiplexer, 
upon  command  from  the  program,  brings  various  segments  of 
the  IFE  file  into  main  memory  buffer  areas.  These  are 
shown  inside  the  common  area  enclosed  with  dashed  lines. 

The  IFE. TIM  block  represents  the  IFE  modules  which 
interface  with  the  buffer  areas.  The  IFE. DIM  block 
represents  the  modules  which  communicate  with  the  user. 

An  example  of  some  of  the  capabilities  of  the  IFE  are 
shown  in  Figure  4-4.  This  example  was  generated  during  the 
execution  of  the  IRSS  module  SIMSYS.  In  the  first  line  the 
user  is  asked  what  procedure  he  wants  to  use.  The  reply  is 
SIMSYS.  Next,  the  user  is  asked  to  provide  values  for  the 
input  parameters  of  the  module  SIMSYS.  The  user  does  not 
know  what  to  enter  for  the  parameters  so  he  replies  with: 
"?".  The  IFE  then  retrieves  descriptive  information  on 
each  parameter  and  again  asks  the  user  to  provide  a  value 
for  each  parameter.  In  this  example  the  user  entered 
values  of  li  for  N2,  0.2  for  FS,  i  for  ICFOR,  and  nothing 
for  NORMFT,  RNGCEL,  TIME,  and  ISDUMP . 

When  the  user  is  asked  to  enter  another  command  he 
enters  PHENC.  Since  this  module  generates  a  phase  code  and 
places  it  into  a  waveform  file  the  user  must  specify  where 
to  store  it.  His  reply  was  PC.  The  system  detected  that 
no  waveform  named  PC  had  been  setup  so  it  allocated  a 
temporary  file  with  that  name.  Next  the  user  is  asked  to 
enter  input  parameters.  The  user  knows  he  wants  to 
generate  a  13  bit  Barker  code  but  can't  remember  which 
value  of  MODEPH  is  appropriate.  Therefore  he  enters  13  in 
the  field  for  NSUBP  and  ?  in  the  field  for  MODEPH.  The  IFE 
responds  by  printing  the  valid  values  of  MODEPH  and  their 
meanings.  The  user  enters  a  1  to  cause  a  Barker  code  to  be 
generated. 

Examples  of  error  detection  by  the  IFE  are  included  in 
the  user  manual  and  will  not  be  reiterated  here. 
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4-4  Example  of  IFE  Information  retrieval  from 
RADSIM  Data  Base 
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Figure  4-4  Example  of  IFE  Information  Retrieval  from 
RADSIM  Data  Base  (cont.) 
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4.5. 1.2  RADSIH  DATA  BASE 


The  RADSIM  data  base  accessed  by  the  IFE  contains  the 
following  information-. 

Commands 

Module  Names 

Module  Parameters 

Module  Array  Elements 

Messages 

Prompt  Statements 

The  module  parameter,  array  element,  and  name  entries 
include  descriptive  information  such  as:  units  of  measure, 
valid  parameter  ranges,  warnings,  and  a  general  discription 
of  the  item. 

4.5.2  HELP  PROCESSOR 

The  HELP  processor  serves  as  a  direct  interactive 
interface  between  the  user  and  the  RADSIM  data  base.  When 
the  HELP  processor  is  activated  all  user  requests  are 
routed  directly  to  it.  In  response  to  each  request  to 
define  a  symbolic  name,  the  HELP  processor  searches  the 
RADSIM  data  base  for  the  symbolic  name  in  question.  If  it 
is  found  then  all  information  available  pertaining  to  it  is 
printed.  Examples  of  the  HELP  processor  operation  are 
contained  in  the  user  manual  and  will  not  be  reiterated 
here . 

4.5.3  WAVEFORM  PROCESSING  SUBSYSTEM 

The  functional  block  diagram  of  the  WPS  load  module  is 
shown  in  Figure  4-5.  This  load  module  is  structured  so 
that  computer  memory  requirements  are  minimized.  This  is 
achieved  by  having  all  of  the  simulated  waveforms  and 
simulation  modules  resident  in  disc  files.  The  waveforms 
are  contained  in  the  waveform  files  and  the  simulation 
modules  are  resident  in  an  HSTAR  file.  The  GCOS  operating 
system  automatically  takes  care  of  loading  the  simulation 
modules  from  HSTAR.  Therefore,  this  is  not  shown  in  the 
diagram . 

The  input  commands  and  data  generated  by  the  ITS  are 
the  only  source  of  input.  These  inputs  are  multiplexed 
into  the  SMEST  and  the  Module  Parameter  Table  <MPT)/  Module 
Array  Table  <MAT).  The  SMEST  controls  the  simulation 
execution  and  the  MPT/MAT  contains  the  module  parameters. 

As  each  simulation  is  being  performed  a  MPF  can  be 
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COMMON 


constructed.  In  the  event  a  simulation  is  to  be  modified 
and  rerun,  the  MPF  is  used  as  the  primary  source  of  input. 

In  the  figure  the  Waveform  Multiplexer,  Disc  File  I/O 
modules,  Waveform  Buffers,  and  VPB  I/O  modules  perform  the 
manipulations  required  to  move  segmented  data  arrays 
between  memory  and  the  disc  files. 

4.B.4  USER  AID  PROCESSOR 

The  UAP  is  a  simple  processor  which  causes  block 
diagrams  of  prototype  radar  subsystems  to  be  drawn  and  then 
asks  the  user  which  blocks  of  each  subsystem  he  wishes  to 
include  in  his  simulation.  Once  the  user  has  answered  all 
the  questions  regarding  the  desired  simulation  structure 
the  IFE  processor  is  used  to  request  the  module  input 
parameters  for  each  module.  In  Appendix  B  of  this  report 
an  example  is  provided  which  illustrates  the  use  of  the  UAP 
in  setting  up  a  simulation  job.  This  example  includes  the 
block  diagrams  and  the  question/answer  sequence  used. 
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SECTION  S 
CONCLUSIONS  AND 
RECOMMENDATIONS 


5.1  CONCLUSIONS 

The  results  obtained  during  this  investigation  have 
indicated  that  all  objectives  of  the  program  have  been 
attained.  The  primary  objective  was  to  modify  the  IRSS 
such  that  it  was  easier  to  use.  In  order  tG  achieve  this 
goal  for  both  the  novice  and  experienced  user  two  different 
approaches  were  used  in  operating  the  IRSS.  First  ,  a 
totally  interactive  capability  was  established  such  that  a 
user  could  command  modules  to  be  executed  and  look  at  the 
results  immediately,  thereby  getting  the  fastest  possible 
turnaround.  Second ,  a  computer  directed  procedure  was 
implemented  which  leads  the  user  through  a  series  of  steps 
in  order  to  set  up  a  simulation.  The  following  is  a  list 
of  conclusions  which  relate  to  the  various  subsystems  that 
form  the  IRSS  = 

1.  The  incorporat ion  of  interactive  information  retrieval 
from  the  IRSS  data  base  has  significantly  reduced  the 
amount  of  information  that  the  user  must  remember  and 
provides  for  extensive  run  time  error  checking.  Since 
the  process  is  interactive  the  errors  are  flagged  as 
they  occur  and  the  user  is  required  to  correct  them 
immediately.  The  incorporation  of  the  Interactive 
Front  End  <IFE)  software  into  the  IRSS  was  the  biggest 
single  factor  in  improving  the  utility  of  the  IRSS. 

2.  The  User  Aid  Processor  (UAP)  was  originally  developed 
to  aid  only  the  novice  user.  It  now  appears  that  the 
UAP  could  be  extended  to  help  not  only  the  novice  but 
also  the  occasional  user  who  knows  what  he  wants  to  do 
but  has  forgotten  some  of  the  mechanics  of  utilization. 
For  the  highly  experienced  user  the  user  directed  mode 
will  always  be  the  most  efficient. 

3.  The  conversion  of  the  IRSS  from  batch  execution  to  time 
sharing  was  very  successful.  The  CPU  time  requirements 
have  increased  very  little  due  to  the  added  overhead. 
The  memory  requirements  have  dropped  from  70K  to  34K 
which  is  a  significant  reduction.  In  performing  this 
conversion  the  old  capabilities  of  the  IRSS  were 
preserved  and  actually  were  extended. 
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4.  The  DUIS  can  be  used  to  plot  data  generated  by  any  TSS 
program  run  under  GCOS.  This  is  done  by  using  the  OUIS 
plot  interface  module,  PLOTD,  which  is  resident  in  the 
H618Q  under  account  CF4IRSS. 

To  summarize,  the  IRSS  in  its  current  configuration  is 
much  more  forgiving  than  its  predecessor.  The  key  element 
in  "humanizing"  this  simulation  program  was  the 
incorporat ion  of  a  sophisticated  processor  to  communicate 
with  the  user.  This  processor  is  capable  of  detecting  user 
errors  as  they  occur  and  requesting  correction.  Also  the 
processor  has  access  to  a  data  base  of  information  on 
module  characteristics,  parameters,  I/O  requirements,  etc. 


5.2  RECOMMENDATIONS 

In  view  of  the  results  presented  in  this  report  and 
the  potential  applications  of  the  radar  simulation  model  in 
evaluating  numerous  radars,  it  is  recommended  that  further 
studies  be  performed  to  improve  the  usefulness  of  the  IRSS. 
The  specific  areas  that  deserve  further  effort  include: 

1.  Upgrade  the  capabilities  of  the  DUIS  by  adding  3 
flexible  disc  drives  and  128K  bytes  of  memory.  The 
incorporation  of  this  equipment  into  the  DUIS  would 
provide  the  following  new  capabilities: 

A.  3D  plots  could  generated  which  would  allow 
ambiguity  diagrams  and  antenna  patterns  to  be  plotted. 

B.  The  IRSS  data  base  could  be  resident  in  the  DUIS 
thereby  reducing  the  cost  of  using  the  H6180. 

c.  A  full  text  editing  and  word  processing  capability 
would  be  available  independent  of  the  H6180. 

D.  The  DUIS  could  function  as  a  standalone  computer 
system  which  would  support  source  file  creation  and 
editing,  FORTRAN  compiler,  load  module  creation  and  job 
execution. 

E.  General  block  diagrams  could  be  generated  for  flow 
charts,  viewgraphs,  etc. 

2.  Modify  the  IRSS  to  allow  more  extensive  modifications 
of  the  Multiple  Pass  File  <MPF>  to  be  made.  Examples 
are  deletion,  insertion,  replacement,  and  skipping  of 
modules.  In  addition  set  up  a  simple  editor  for 
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modifying  Simulation  RUN  Files. 


3.  Expand  the  capabilities  of  the  User  Aid  Processor  so 
that  it  can  be  helpful  to  the  occasional  user  as  well 
as  the  novice.  Provide  for  prestruc tured  simulations 
where  the  simulation  structure  is  laid  out  for  various 
generic  radar  systems  and  the  user  only  has  to  provide 
parameters . 

4.  Expand  the  data  base  to  provide  a  description  of  each 
module  including  block  diagrams  if  appropriate. 

5.  Add  run  time  tests  to  verify  that  the  user  specified 
input  waveforms  for  a  module  are  compatible  with  the 
charac ter ist ics  of  the  module.  For  example,  it  would 
be  incorrect  to  specify  time  domain  input  waveforms  for 
a  module  which  processes  frequency  domain  data. 

6.  Add  a  range  and  angle  track  capability,  an 
endoatmospher ic  chaff  model,  a  more  accurate  ECM  model, 
and  multiple  maneuvering  target  modules. 

7.  Perform  more  research  into  the  development  of  general 
purpose  front  end  processors  for  application  programs. 
This  would  be  par ticular ily  helpful  in  supporting  the 
development  of  some  advanced  simulations  for  such 
systems  as  the  Space  Based  Radar. 

8.  Provide  for  spooling  of  plot  files  generated  during  a 
simulation  such  that  the  IRSS  can  be  run  from  any 
terminal  and  the  plots  retrieved  later  via  the  DUIS. 

9.  Add  a  capability  for  processing  a  system  noise 
cumulative  distribution  function  (CDF)  and  noise+target 
CDF's  to  generate  Pd  curves  for  a  system. 

10.  Incorporate  filter  design  programs  into  the  IRSS  so 
that  the  user  can  specify  filters  in  terms  of  filter 
type  and  filter  charac ter ist ics  such  as  number  of 
poles,  corner  frequency,  rolloff  rate,  etc.  The  filter 
modules  currently  in  the  IRSS  require  that  filters  be 
specified  in  terms  of  S-plane  or  Z-plane  pole/zero 
locations  or  digital  filter  coefficients. 


41 


.  ir*r~ 


wscsa.ua  pass  hunk-mot  ulned 


SECTION  6 
REFERENCES 


1.  Hancock,  R.  J.  and  Cleveland,  F.  H.  ,  Endo 
Atmospher ic-Exo  Atmospheric  Radar  Modelino  <U) , 

RADC-TR -76-186,  Vol.  1,  Griffiss  AFB,  New  York,  June 

76.  Part  1  (A030555)  Part  2  (A030496)  and  Part  3  (A030504) 

2.  Hancock,  R.  J.,  Graphics  Control  Sustem  Computer 
Prooram  Documentation,  submitted  to  RADC,  Griffiss  AFB, 
February  79. 

3.  Hancock,  R.  J.,  Interactive  Radar  Simulator  General 
Description .  submitted  to  RADC,  Griffiss  AFB,  May  79. 


43 


FRBC1DIN0  FiOK  BUNK-NOf  riU£0 


APPENDIX  A 
AN  EXAMPLE  OF 
INTERACTIVE  EXECUTION 


In  this  appendix  an  example  is  provided  which 
illustrates  the  use  of  the  IRSS  in  an  interactive  manner. 

In  this  example  a  Simulation  RUN  File  <SRF>  and  a  Multiple 
Pass  File  (MPF)  were  created. 

In  the  listing  which  follows,  copies  of  the  plots  that 
were  generated  have  been  inserted  in  the  text  at  the  point 
of  occurrence.  It  should  be  noted  that  after  each  plot  was 
generated  the  statement  "Type  CR  When  Ready"  was  printed. 

If  a  hardcopy  of  the  plot  was  desired  it  was  made  at  that 
time.  In  the  listing  all  user  replies  are  underlined. 

Null  responses  are  indicated  by  an  underline  only. 

In  the  example  which  follows  a  13  bit  Barker  code  was 
generated  and  passed  through  a  filter.  Then  noise  was 
added  to  it  and  the  resulting  waveform  was  digitized  and 
passed  through  a  digital  decoder.  It  should  be  noted  that 
this  example  was  chosen  only  to  illustrate  the  use  of  the 
IRSS  in  an  interactive  manner  and  is  not  intended  to 
represent  any  particular  system  design.  In  this  example 
the  use  of  the  SRF  and  the  MPF  is  not  shown. 


YFO^T 

« 

*  RUN  IRSS 
IRSS  Started 

For  a  List  of  Coplands  Type:  ?  at  CMD  Level 
Enter  CMD 

*  OPENR_ 

Enter  RERUN  File  Name 
=  DIGDECQD 

File  Does  not  Exist-DIGDECOD 
Creating  Neu  File 
Enter  ChD 

*  SIMS YS 

.. 


Enter  N2 
*  11,  2 
v  _  -41 


,FS  , ICFOR  ,NORhfT  ,RNGCEL 


Enter  TIME  ,ISBUMP  , 


Simulation  Time  Span  (TTL)  =  0.10240E  05 

Enter  ChD 

*  .PHENC^ 

Enter  1  Output  Waveform  Names 
=  PC 

Temporary  File  Created  For:PC 

Enter  N5UBP  ,MODEPH  ,ICODE  ,NSR  , IPY 

*  13,1 

Enter  CMD 

*  BGLOOP 

Enter  TIME  ,NREPET  , 

*  ,• 
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Enter  CMD 

*  PCODXY^ 

Enter  i  Input  Uaweforn  Nanes 
= 

Enter  2  Output  Uaweforn  Nanes 
=  Jli,A2^ 

Tenporary  File  Created  For  hi 
Tenporary  File  Created  For:A2 

Enter  IPHH  ,SIHF0  ,NGRNFT  ,SPU  .NSUBP 

*  cn  '  '  ' 

Enter  SUTIh  ,RISTIH  ,FALTIN  ,TSTART  ,VPEAK 

*  10. ,10. ,10. ,75. 


Enter  CMD 
*  XF,IH- 

Enter  2  Input  Uaweforn  Nanes 

*  A1.A2 

mr ■+.  m+rn 

Enter  2  Output  Uaweforn  Nanes 
=  Bi,B2 

Tenporary  File  Created  For;Bi 
Tenporary  File  Created  For>B2 

Enter  CMD 

*  PLOTTL 

Enter  1  Input  Uaweforn  Nanes 
=  Ai 


Enter  ST  ,RNG  ,NSKP  , 
*  I  .,iOOJ)_ 

Plot  Xfer  Started 
Xfer  Conplete 


i 


2.000 


gure  A-l  Phase  Coded  Waveform 


Type  CR  U'hen  Ready 

Enter  CHD 
A  PLOTDB^ 

Enter  2  Input  Uaveforn  Nanes 
=  B1,B2 

Enter  ST  ,RNG  ,NSKP 

Plot  Xfer  Started 
Xfer  Complete 

*  0 


Type  CR  When  Ready 


* 

j 


Enter  Lrtl> 

*  FILT_ 

Enter  2  Input/Output  Uaveforn  Hawes 

*  Bi,B2 

Enter  SF  , 

*  i.OE-08 

Enter  NP  , 

A  4 

ENTER  FPOLE  (2.  4) 

A  -0  C092388,0 .0038268 

t  j  -  -ru  ■  *  *  •  »u.  »■»».-  *■  ■* 

=  -0.0092388,-0.0038268^ 

=  -0.0038268,0.0092388  ^ 

=  -0.0036268,-0.0092388 

..  -  -s  ^ 

Enter  NZ  , 

*  0 


Enter  CMD 
*  IXFRH 

Enter  2  Input  Uaveforn  Nawes 
=  Bi,82^ 

Enter  2  Output  Wavefsr*  Hawes 
=  Ai ,A2 
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j 


Enter  CtfD 
NOISE 


Enter  2  Input/Output  Vlaveforn  Nanes 
S  ,Ai,A2 

Enter  SIGMA  , 

*  OOi 
— ■» 


Enter  ChD 
A  PLOTTR 

Enter  1  Input  Waveforn  Kanes 
=  A1 


Enter  ST  ,RNG  ,NSKP 
‘  ,1080. 


Plot  Xfer  Started 
Xfer  Complete 

8 
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2.eee 


igure  A-3  Phase  Coded  Waveform  4-  Noise 
(Noise  SIGMA  =  0.001) 


I 


Type  CR  When  Ready 


Enter  CrtD 


*  PLOT  TR 

Enter  1  Input  Waveforn  Names 
=  A2 


Enter  ST  ,RNG  ,NSXP 

*  ,1000. 

Plot  Xfer  Started 
Xfer  Complete 
=  0 

Type  CR  When  Ready 


Enter  CMD 


WARNING  Nonlinear  Transfer  functions 

nay  generate  harmonics  which  exceed  FS/2 

Enter  1  Input  Waveform  Nines 
=  A1 

m  ■  •« 

Enter  i  Output  Waveform  Names 

=  II 
»>  ^ 

Temporary  File  Created  For.Ii 

Enter  XLSB  ,NBITS  , IROFF  ,ADCFS  , 

.05, 10, ,.020 

Enter  CrtD 
*  PLOTTR 

Enter  1  Input  Uaveforn  Names 
=  II 

Enter  ST  ,RNG  ,NSKP 


Plot  Xfer  Started 
Xfer  Complete 

*  « 
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i 


Type  CR  When  Ready 


Enter  CMD 
*  IHLIH 

UARNING:  Nonlinear  Transfer  functions 

way  generate  harnonics  which  exceed  FS/2 

Enter  1  Input  Uaveforn  Nanes 

=  Ji_ 

Enter  i  Output  Uaveforn  Nanes 
=  11 


Enter  CHD 

A  _PLQITtL 

Enter  i  Input  Uaveforn  Nattes 
=  II 


Enter  ST  ,RNG  ,NSKP 

*  ,1000. 


Plot  Xfer  Started 
Xfer  Complete 

8 
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Lgure 


Type  CR  When  Ready 

Enter  CMD 
*  DIGTFL 


WARNING^  Nonlinear  Transfer  functions 

r.ay  generate  harr.onics  which  exceed  FS/2 

Enter  i  Input  l.'avefor«  h'aries 

=  II, 

Enter  i  Output  Waveforn  Nanes 
=  12 

Tenporary  File  Created  For  12 
Enter  ISPAC  , 

A 

_1 

Enter  NT APS  , 

*  1J5_ 


ENTER  I TAP  (2,  13) 
*  JjL1- 

"  Sid- 

"  JLii  . 

=  :i,l_ 


Enter  CUD 
*  PLQTTR- 

Enter  i  Input  Waveforn  Nanes 
=  12 


Enter  ST  ,RNG  ,NSKP 

*  ,1000. 


Plot  Xfer  Started 
Xfer  Complete 


> 
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Type  CR  Wnen  Ready 

Enter  CHD 

*  ENLOOP 

■  '•*  •  "* 

Enter  CMD 

*  CLOSER^ 

Enter  CMD 

*  STOP 

4-  . - « 

IRSS  Termnating 
t  BYE 


A- 16 


The  simulation  that  was  setup  in  this  example  was 
subsequently  rerun  with  the  noise  SIGMA  =  0.5.  The  plots 
obtained  for  this  case  are  shown  in  Figures  A-7,  -8,  -9, 

and  -10. 
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APPENDIX  B 
AN  EXAMPLE  OF 

USER  AID  PROCESSOR  EXECUTION 


In  this  appendix  an  example  is  provided  which 
illustrates  the  use  of  the  User  Aid  Processor  <UAP)  in 
setting  up  a  simulation.  The  UAP  utilizes  block  diagrams 
to  aid  the  user  in  visualizing  the  structure  of  the 
available  options.  These  block  diagrams  are  shown  in 
Figures  B-l  through  B-6.  In  Figure  B-l  the  available 
subsystems  are  shown.  In  Figures  B-2  through  B-6  the 
prototype  block  diagrams  of  the  subsystems  are  shown. 

In  the  listing  which  follows  the  occur ranee  of  each 
block  diagram  is  indicated  by  its  Figure  number  and  all 
user  replies  are  underlined.  Null  responses  are  indicated 
by  an  underline  with  no  characters  above  it. 

In  the  example  which  follows  a  50  bit  Pseudo  Random 
Binary  Sequence  <PRBS)  phase  coded  waveform  was  generated, 
then  contaminated  with  noise  and  filtered.  The  resulting 
waveform  was  then  passed  through  a  matched  filter  and  a 
CFAR  processor.  It  should  be  noted  that  this  example  was 
chosen  only  to  illustrate  the  use  of  the  UAP  and  is  not 
intended  to  represent  any  particular  system  design. 
Execution  of  the  simulation  RUN  File  (PRBSCODE)  created  in 
this  example  is  shown  in  Appendix  C. 


NG  BLOCK  DIAGRAM 


Available  hatched  Filter  Options  Follow: 

1  Xnit  Oaveforn  Conjugate 

2  S-Plane  Specification 

3  Direct  Specif ication 

4  Transversal  Filter  (SAW  Device) 

5  None 

Enter  Index 


Detector? 

=  Y 

Block  Diag  Xfer  Started 

=  0 

Digital  or  Analog?  (D  or  A) 
HTI  Processor? 

=  JL 

CFAR  Processor? 

=  Y 

Block  Diag  Xfer  Started 

=  0 

CFAR  Processor? 

-  N_ 

Sweep  Integrator? 
Statistical  Analysis? 

3  JL 

Plot  Video? 

=  Y 


Figure  B-5 


Figure  B-6 


B-9 
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MODULE  EXECU'.IEN  SEQUENCE  TABLE 


MSN 

MODULE 

WAVEFORM  LIST 

1 

PHENC 

PC 

2 

PCODXY 

PC 

Ai 

A2 

3 

XFRM 

Ai 

A2 

Bi 

B2 

4 

MATFIL 

B1 

P2 

XI 

X2 

S 

NOISE 

Al 

A2 

6 

XFRM 

Al 

A2 

Bi 

B2 

7 

FILT 

Bi 

B2 

8 

MOVE 

XI 

X2 

Ai 

A2 

9 

MULT 

Ai 

A2 

Bl 

B2 

IB 

IXFRM 

Bi 

B2 

Ai 

A2 

ii 

XYTOM 

Al 

A2 

Al 

12 

CLEART 

A2 

13 

XFRM 

Al 

A2 

Bl 

B2 

14 

FWDET 

Ai 

15 

CFAR 

Ai 

Ai 

16 

PLOTTR 

Al 

Insert  A  Plot? 
=  Y 


Enter  Module  Sequence  Nunber  (MSN) 
=  2 


Enter  Plot  Type  Index: 

1  Single  Channel 

2  Envelope 

3  Envelope  Squared 

4  Envelope  in  dB 


Enter  Waveform  to  be  Plotted 
=  Aj_ 

Insert  A  Plot? 

=  ’  Y 


Enter  Module  Sequence  Nunber  (MSN) 
=  3 


Enter  Plot  Type  Index 

1  Single  Channel 

2  Envelope 


3  Envelope  Squared 

4  Envelope  in  dB 

Enter  Waveforns  to  be  Plotted; 
Waveforn  41  = 

=  Bi. 

Uaveforn  #2  = 

=  B2__ 
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Insert  A  Plot? 
=  Y 


Enter  Module  Sequence  Nuwber  (MSN) 


Enter  Plot  Type  Index: 

1  Sinqle  Channel 

2  Envelope 

3  Envelope  Squared 

4  Envelope  in  dB 


Enter  Waveform  to  be  Plotted 
=  Al^ 

Insert  A  Plot? 

=  Y 

Enter  Module  Sequence  Number  (MSN) 
=  11 


Enter  Plot  Type  Index-. 

1  Sinqle  Channel 

2  Envelope 

3  Envelope  Squared 

4  Envelope  in  dB 

Enter  Waveform  to  be  Plotted 
=  J\l_ 

Insert  A  Plot? 

=  N 

Set  Up  Multiple  Pass  Loop? 


Enter  First  Module  Sequence  Number  of  Loop 


Enter  Last  Module  Sequence  Nunber  of  Loop 
*  16 

Enter  RERUN  File  Name 

-raw 

File  Does  not  Exist-PRBSCODE 
Creatinq  New  File 


At  this  point  in  the  setup  procedure  the  dimensions 
(Frequency  X  Tine)  of  the  sample  space  to  be  used 
in  the  simulation  must  be  specified.  Since  this 
aspect  of  the  simulation  setup  is  of  critical  importance 
more  information  is  available  if  you  need  it.  Do 
you  need  more  information? 

=  Y 


B-ll 
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1.  The  frequency  dimension  is  determined  by  the  sampling 
rate  parameter,  FS 

2.  The  time  di'-.-Msion  is  determined  by  the  nanmun 
number  of  samples  to  be  used  in  representing  the 
waveforms.  For  compatibility  with  the  Discrete 
Fourier  Transform  algorithm  used  in  the  IRSS,  the 
maximum  number  of  samples  must  be  a  power  of  2. 
Therefore,  the  parameter  N2  is  used  to  determine  the 

tine  dimension  of  the  sample  space  ( TTL )  as  follows; 

TTL=(i.0/FS)*(2**N2> 

Do  you  need  more  information  to  select  FS  and  N2? 


1.  Normally  the  spectral  width  of  the  transmitted 
waveform  will  determine  the  minimum  acceptable 
value  of  FS.  If  FS  is  too  small,  then  frequency 
components  greater  than  FS/2  will  be  folded  into 
the  sample  space  (aliased)  and  cause  errors. 

2.  To  select  a  minimum  value  of  TTL  you  must  roughly 
estimate  the  total  time  span  required  to  represent 
the  transmitted  waveform  after  it  has  been  convolved 
with  all  transfer  functions  included  in  the 
simulation.  Once  you  estimate  the  minimuim  TTL, 
multiply  it  by  FS  to  estimate  the  number  of  samples 
required.  Then  round  that  number  up  to  the  nearest 
power  of  2.  The  following  is  provided  for  your 
convenience; 


N2 

2**N2 

9 

512 

10 

1024 

il 

2048 

12 

4096 

13 

8192 

14 

16384 

If  the  number  of  samples  chosen  to  represent  the 
waveforms  is  inadequate,  tine  wraparound  will  occur. 


, FS  , ICFOR  ,NORNFT  ,RNGCEL  , 


, ISDUMP  , 


,KODEPH  , ICODE  ,NSR  ,IPY 


SI/JSYS 

Enter  N2 
*  11,2 


Enter  TIME 


PHENC 

Enter  NSUBP 
*  50,2, ,8 
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CFAR 

Enter  TAVG  JrtlDL 
*  ? 


Pari*:TAVG 

Width  of  averaging  window  used  in  deternining  video 
gain 

PARAMTAVG  UNITS  ARE :  Nanoseconds 

ENTER  TAVG 
=  1000. 

ParanTHIDL 

Width  of  the  central  region  not  included  in 
averaging  window 

TI  <=  THIOL 

PARANTHIDL  UNITS  ARE:  Nanoseconds 

ENTER  TMIDL 
=  101.0 

PLOTTR 

ENIOOP 

Create  Another  Run  File? 

= 

Enter  CHD 
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APPENDIX  C 


AN  EXAMPLE  OF 

SIMULATION  RUN  FILE  EXECUTION 


In  this  appendix  an  example  is  provided  which 
illustrates  the  execution  of  a  simulation  from  input  data 
contained  in  a  Simulation  RUN  File  <SRF>.  The  SRF  used  in 
this  example  (PRBSCODE)  was  generated  through  the  use  of 
the  UAP .  Creation  of  the  RUN  file  PRBSCODE  is  documented 
in  Appendix  B. 

In  the  listing  which  follows  copies  of  the  plots 
produced  by  the  IRSS  have  been  inserted  in  the  text  at  the 
point  of  occurrance.  It  should  be  noted  that  after  each 
plot  was  generated  the  statement  "Type  CR  When  Ready"  was 
printed.  This  caused  execution  of  the  simulation  to  cease 
in  order  that  a  hardcopy  of  the  plot  could  be  made  on  the 
conversation  monitor.  In  the  listing  all  user  replies  are 
underlined.  Null  responses  are  indicated  by  an  underline 


RUN  IRSS, 

1RSS  Started 

For  a  List  of  Commands  Type;  Y  at  CND  Level 
Enter  CHD 

*  RUN  PRBSCODE 

Enter  CND 


SINSYS 

N2  =  ii,FS  =  2  OOOOE-Oi, 

»  ’ 
Simulation  Time  Span  (TTL)  =  0 . 1 0240E  OS 


Enter  CND 
PHENC 

Enter  1  Output  Waveform  Names 
PC 

Temporary  File  Created  For=PC 
NSUBP  =  50,NODEPH= 

a  1 


Enter  CMD 

BGLOOP  - 

NREPET=  0, 

I 

Enter  CHD 
PCODXY 

Enter  i  Input  Waveform  Names 
PC 

Enter  2  Output  Waveform  Names 
A1  A2 

Temporary  File  Created  ForAi 
Temporary  File  Created  Fer;A2 
SPW  =  5.0000E  0i,TSTART=  5.0000E  02, 


Enter  CMD 
PLOTTR 

Enter  i  Input  Waveform  Names 
Ai 

Enter  ST  ,RNG  ,NSKP 
*;  0,4000. 


Plot  Xfer  Started 
Xfer  Complete 


Type  CR  When  Ready 


Enter  CHD 
XFRN 

Enter  2  Input  Waveforn  Wanes 
A1  A2 

Enter  2  Output  Waveforn  Nanes 
61  62 

Temporary  File  Created  For^Bl 
Temporary  File  Created  For:B2 

Enter  CMD 

PLOTDB 

Enter  2  Input  Waveforn  Wanes 
61  B2 

Enter  ST  ,RNG  ,N SKP 


A  ? 
i  >c 


Plot  Xfer  Started 
Xfer  Conplete 
'  0 


C-4 


60.000 


FREQUENCY  -  GHZ 

Figure  C-2  Spectrum  of  PRBS  Waveform 


Type  CR  Uhen  Ready 


Enter  CMD 
NATFIL 

Enter  2  Input  Uaveforn  Nanes 
B1  62 

Enter  2  Output  Wavefor*  Hanes 
XI  X2 

Temporary  File  Created  For;Xl 
Temporary  File  Created  For;X2 

Enter  CMC 

NOISE 

Enter  2  Input/Output  Waveforn  Nanes 
A1  A2 

SIGMA  *  i.OOOOE  00, 

* 

Enter  CMC 
PLOTTR 

Enter  1  Input  Wavefortt  Nanes 


Enter  ST  ;RNG  ,NSKP 

*  o 
>  >- 


Plot  Xfer  Started 
Xfer  Conplete 


C-6 


Type  CR  When  Ready 


Enter  CHD 
XFRH 

Enter  2  Input  Waveforn  N3nes 
A1  A2 

Enter  2  Output  Waveforn  Names 
Bi  B2 

Enter  CNB 

FILT 

Enter  2  Input/Output  Waveforn  Names 
Bi  B2 

SF  =  3C000E-02. 

FPOLE  (i  =  -3 . 000 0E-02,  0.  ,Z 

HP  =  1 

NZ  =  0 

I 

Enter  CHD 
HOVE 

Enter  2  Input  Waveforn  Names 
Xi  X2 

Enter  2  Output  Waveforn  Hanes 
At  A2 

Enter  CUD 

MULT 

Enter  2  Input  Waveforn  Hanes 
A1  A2 

Enter  2  Input/Output  Waveforn  Names 

BI  B2 
Enter  CMD 
IXFRM 

Enter  2  Input  Waveforn  Names 
BI  B2 

Enter  2  Output  Waveforn  Hanes 
Ai  A2 

Enter  CHD 


Enter  2  Input  Waveforn  Hanes 
Ai  A2 

Enter  i  Output  Waveforn  Names 


Enter  CMC 
PLOTTR 

Enter  i  Input  Waveforn  Names 
Al 

Enter  ST  ,RNG  ,NSKP  , 

A  4  9  9 

t 


Plot  Xfer  Started 
Xfer  Complete 
■  6 


C-8 


Type  CR  U*ien  Ready 


Enter  CMD 
CLEAR T 

Enter  1  Output  Waveforn  Nanes 
A2 

Enter  CMD 
XFRN 

Enter  2  Input  Waveforn  Nanes 
Ai  A2 

Enter  2  Output  Waveforn  Nanes 
Bi  B2 

Enter  CMD 

FWDET 

WARNING:  Nonlinear  Transfer  functions 

nay  generate  harnonics  which  exceed  FS/2 

Enter  1  Input  Waveforn  Nanes 
Al 

Enter  1  Output  Waveforn  Nanes 


Enter  CMD 
CFAR 

WARNING:  Nonlinear  Transfer  functions 

nay  generate  harnonics  which  exceed  FS/2 

Enter  i  Input  Waveforn  Nanes 
Ai 

Enter  i  Output  Waveforn  Nanes 
Al 

TAVG  =  i.QOOOE  03,TMIDL  =  i.OOOOE  02, 

* 

Enter  CMD 
PLOTTR 


Enter  i  Input  Waveforn  Nanes 


Enter  ST  ,RNG  ,NSKP 
>  >2 


Plot  Xfer  Started 
Xfer  Conplete 

0 


C-10 


Enter  CrlD 


ENLOOP 
Enter  CHD 

CLOSER 


C- 12 


At  this  point  in  the  example  the  simulation  as  defined 
by  the  file  PRBSCODE  had  been  run.  In  performing  the 
simulation  a  Multiple  Pass  File  (MPF)  was  setup  using  the 
commands  BGLOOP  and  ENLOOP .  In  the  listing  which  follows 
parameter  of  one  module  was  changed  and  the  simulation  was 
rerun  using  the  MPF  file.  The  MPF  was  printed  using  the 
DMP  MPF  command.  Then  the  parameter  SIGMA  of  the  module 
NOISE  was  changed  using  the  MODIFY  command.  Finally  the 
modified  MPF  was  run  using  the  RUN  MPF  command.  In  this 
part  of  the  example  hardcopies  of  some  plots  were  not  made 
since  they  were  the  same  as  those  generated  earlier. 


Enter  CrtD 


*  BMP  MPF 


i 

PGLOOP 

31S 

1 

0 

2 

PCG9XY 

405 

2 

0 

3 

PLGTTR 

3G7 

3 

0 

A 

XFRH 

219 

4 

0 

$ 

PLQID6 

306 

S 

8 

6 

HATFIL 

109 

6 

0 

7 

NulSE 

402 

7 

0 

8 

PLuTTR 

307 

8 

0 

9 

XFRM 

219 

9 

0 

10 

FILT 

407 

10 

11 

11 

MOVE 

108 

12 

0 

12 

MllT 

204 

13 

0 

13 

iXvRM 

220 

14 

0 

1 A 

XtTOM 

105 

15 

0 

IS 

PLOTTR 

307 

16 

0 

16 

CLEART 

143 

17 

0 

17 

XFSh 

219 

18 

0 

18 

FWDET 

416 

19 

0 

19 

CF  AR 

459 

20 

0 

20 

PLOTTR 

307 

21 

0 

Enter  END 

*  MODIFY 

■r.r--  ...  •  *• 

Enter  1STEP 
A  7 


Module  =  NOISE 

Enter  SIGMA  , 
*  3.0 


Enter  ISTEP 

A 


Enter  CMD 

*  RUN  MPF 

»  .  -4» 

Module  =  EGLOQP 
Module  =  PlODXY 
Module  =  PLGTTR 

Enter  ST  ,RNG  ,IySKP 

*  ,10. 


Plot  Xfer  Started 
Xfer  Complete 
=  8 


C-U 


V 

AD-A087  562 

UNCLASSIFIEn 


2*2 


SIMULATION  TECHNOLOS*  INC  NASHVILLE  TN  F/S  17/9 

INCREASED  OPERATIONAL  FACILITY  OF  THE  IRSS.(U) 

MAY  80  R  J  HANCOCK  F30602-79-C-0043 

RADC-TR-80-150  NL 


Module  =  XFRH 
Module  *  PL0TD6 


Enter  ST  ,RNG 

*  ,01 

v  i  —  >•»«*» 

Plot  Xfer  Started 
Xfer  Complete 
=  0 

Type  CR  Uhen  Ready 


Module  =  MATFIL 

Module  =  NOISE 

Module  =  PLOTTR 

Enter  ST  >RNG 
*  2 


Plot  Xfer  Started 
Xfer  Complete 


,NSKP 


,NSKP 


Type  CR  When  Ready 

Module  =  XFRH 
Module  =  FILT 
Module  =  MG^E 

Module  =  MULT 
Module  =  IXFRM 

Module  =  XYTOM 

Module  =  PLOTTR 

Enter  ST  ,RNG  ,NSKP  , 

A  ? 

>  >c 

Plot  Xfer  Started 
Xfer  Complete 
=  D 


C-17 


1000E+01 


Figure  C-7  Matched  Filter  Output  Waveform 
(Noise  SIGMA  =3.0) 


Type  CR  When  Ready 

Module  =  CLEART 
Module  *  XFRH 
Module  =  FWBET 
Module  '  CFAR 
Module  =  PLOTTR 

Enter  ST  ,RNG  ,NSKP 

A  2 
>  ic 

Plot  Xfer  Started 
Xfer  Conplete 

*  0 


Enter  CUD 
*  STOP 

1RSS  TeminaTing 
I  6  YE 


? 


3 

i 


C-21 


APPENDIX  D 
LIST  OF  ACRONYMS 


Acronyms  which  are  related  to  the  Honeywell  6180  computer 
or  its  operating  system  are  indicated  by  "(Honeywell ) " 
following  the  entry.  Terms  which  are  obsolete  are  not 
included  in  this  table. 


BDS 

DUIS 

GCOS 

GCS 

HSTAR 

1FE 

IRSS 

ITS 

MAT 

MPF 

MPT 

PRMFL 

RADSIM 

SMEST 

SRF 

TSS 

UAP 

WPS 

YFORT 


Block  Diagram  Subsystem 
Dedicated  User  Interface  Subsystem 
General  Comprehensive  Operating  Supervisor 
Graphics  Control  Subsystem 

Disc  File  Containing  a  Load  Module  (Honeywell) 

Interactive  Front  End 

Interactive  Radar  System  Simulator 

Interactive  Translator  Subsystem 

Module  Array  Table 

Multiple  Pass  File 

Module  Parameter  Table 

Permanent  Disc  Storage  File  (Honeywell) 

Radar  System  Simulation  Model 

Simulation  Module  Execution  Sequence  Table 

Simulation  Run  File 

Time  Sharing  System  (Honeywell) 

User  Aid  Processor 

Waveform  Processing  Subsystem 

Time  Sharing  Fortran  (Honeywell) 


D-l 


MISSION 

of 

Rome  Air  Development  Center 

PAPC  plan*  and  executes  research,  development,  tut  and 
selected  acquisition  programs  In  support  o<$  Command,  Control 
Communication*  and  Intelligence  (C3I)  actlvltiu.  Technical 
and  engineering  support  within  area*  oi  technical  competence 
Is  provided  to  ESP  Program  OUlcu  (POa )  and  other  ESP 
element s.  The  piu.ntu.pal  technical  minion  area*  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
veillance  oi  ground  and  aerospace  objects,  Intelligence  data 
collection  and  handling,  Iniormatlon  system  technology. 
Ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


